REMARKS 

The Examiner is thanked for the performance of a thorough search. No claims have been 
canceled or added in this reply. Claim 1 is amended. Hence, Claims 1-11 and 13-14 are pending in 
this application. All issues raised in the Office Action mailed April 14, 2009 are addressed 
hereinafter. 

SUMMARY OF THE TELEPHONE INTERVIEW 

The Examiner is thanked for granting the courtesy of a telephone interview on July 10, 
2009. Examiner Moutaouakil and Applicant's representatives Edward Becker and Malgorzata 
Kulczycka attended the interview. 

Claim 1 and the following references were discussed: Miida, U.S. Patent Publication No. 
2002/0049839, Lung et al. U.S. 5,533,175 and D'Amanddio et al. U.S. 6,317,387. Although an 
agreement regarding patentability was not reached, significant progress in understanding the 
differences between the approach recited in Claim 1 and the cited prior art references was made. 

The Applicant's representatives explained why Miida, Lung and D'Amanddio do not 
describe or suggest at least the features of "wherein the data format supported by each of the 
plurality of recipient devices is different than the data formats supported by the other recipient 
devices from the plurality of recipient devices," and "wherein the network device status data 
includes identification data that uniquely identifies an intended recipient device so that the report 
data is routed to the intended recipient device," recited Claim 1. 

The Examiner indicated that the explanations are going to be taken into consideration during 
future office actions. 

REJECTION OF CLAIMS 1-6, 8-11 AND 14 UNDER 35 U.S.C. § 103(a) 

In the Office Action, Claims 1-6, 8-11 and 14 are rejected under 35 U.S.C. § 103(a) as being 
anticipated by Miida, U.S. Patent Publication No. 2002/0049839, in view of Lung et al. (U.S. 
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5,533,175) and further in view of D'Amanddio et al. (U.S. 6,317,387). (Office Action, page 3) 



This rejection is respectfully traversed. 

CLAIM 1 

Present Claim 1 recites: 

1. An apparatus for processing network device status data, the apparatus comprising: 

a storage device comprising configuration data stored thereon, wherein the configuration data 
indicates both: 

a set of recipient proprietary unencrypted data formats, wherein each of the 
recipient proprietary unencrypted data formats is understood by only one 
recipient device of a plurality of recipient devices, each of the recipient 
proprietary unencrypted data formats is supported only by one recipient device 
and not by any other recipient device of the plurality of recipient devices, and 
each of the recipient proprietary unencrypted data formats is different than any 
of recipient proprietary unencrypted data formats supported by the other 
recipient devices from the plurality of recipient devices, and 

how to convert network device status data, received from a network device, that conforms 
to a first network device data format into each of the recipient proprietary unencrypted 
data formats supported by the plurality of recipient devices; 
a conversion mechanism configured to 

extract, from the network device status data, recipient identification data that 
uniquely identifies an intended recipient device of the plurality of recipient 
devices, 

select, using the recipient identification data, a recipient proprietary unencrypted 
data format from the set of recipient proprietary unencrypted formats, 

process the network device status data that conforms to the first network device data 
format, and 

generate, based upon the configuration data, the recipient identification data and the 
network device status data, report data that conforms to the recipient 
proprietary unencrypted data format supported by the intended recipient device 
of the plurality of recipient devices, wherein the network device status data 
includes the identification data that uniquely identifies the intended recipient 
device so that the report data is routed to the intended recipient device. 



Support for the amendment is provided at least in paragraphs [8], [18], [24], 27]-[28] and 
[32] of the applicants' specification. 

The approach recited in Claim 1 provides many advantages, especially in networks 
containing devices from various manufacturers and serviced by various vendors. For example, as 
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described in applicants' specification paragraphs [5], [30] and [38], if a network device status data 
uniquely identifies an intended recipient of the device's report, the network device can 
communicate its report directly to the device's manufacturer or vendor that specializes in servicing 
the particular network device. This can be especially beneficial in networks that comprise devices 
serviced by a number of various vendors, and where matching the device status data with the 
correct vendor is cumbersome, unless the "network device status data includes identification data 
that uniquely identifies an intended recipient device so that the report data is routed to the intended 
recipient device," as claimed. 

Furthermore, the ability to send the report data in a "format that conforms to the recipient 
proprietary unencrypted data format that is understood and supported only by the recipient device," 
as claimed, is beneficial to a vendor because it allows the vendor to receive data reports in formats 
that are proprietary to the vendor's recipient device, and that is not supported by any other recipient, 
vendor, competitor, etc. 

Claim 1 recites one or more features that are not described or suggested in Miida, Lung, and 
D'Amanddio, individually or in combination. For example, Miida, Lung, and D'Amanddio, 
individually or in combination, fail to describe or suggest a "set of recipient proprietary 
unencrypted data formats, wherein each of the recipient proprietary unencrypted data formats is 
understood by only one recipient device of a plurality of recipient devices, each of the recipient 
proprietary unencrypted data formats is supported only by one recipient device and not by any other 
recipient device of the plurality of recipient devices, and each of the recipient proprietary 
unencrypted data formats is different than any of recipient proprietary unencrypted data formats 
supported by the other recipient devices from the plurality of recipient devices," recited in Claim 1. 
MIIDA REFERENCE 

In Miida, status information from copiers is sent to users via emails and is also available via 
a website, but Miida does not maintain for each recipient device a "recipient proprietary 
unencrypted data format that is understood only by that recipient device, is supported only 
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by that recipient device, and is different than any other data format supported by any other 
recipient device," as claimed. As depicted in Miida's FIG. 1, Miida's processing center collects 
status information from copiers and provides status reports to users. (Miida, Para [139]) The 
reports are provided to the users in a form of email. Alternatively, the users can access the reports 
via a website. (Miida, paragraph [0156]) Thus, Miida describes only two data formats: an email 
and a webpage. (Miida, paragraph [0156]) However, neither the format of the email nor the format 
of the webpage is proprietary to a recipient device. In Miida, emails in the same format may be sent 
to more than one user. Furthermore, in Miida, more than one user may access the same webpage. 
(Miida, Para [156]) Neither the email format nor the webpage format is proprietary to a recipient 
device, as claimed. Neither the email format nor the webpage format is understood by only one 
recipient device, as claimed. Neither the email format nor the webpage format is supported only by 
one recipient device and not by any other recipient device, as claimed. Neither the email format 
nor the webpage format is different than any of recipient proprietary data format supported by any 
other recipient devices, as claimed. 

In Miida, users are authenticated before they can access data reports, but authentication is 
not a "recipient proprietary unencrypted data format," as claimed. In Miida, a manufacturer or 
a vendor of a copier establishes a website on the Internet through which the users and customers 
may access information about products and information about already purchased copiers. (Miida: 
Para [175]) Most of the pages on the websites are accessible to the public. (Miida: Para [175]) 
However, pages via which status reports from already purchased copiers are available, are 
accessible only to registered customers. (Miida: Para [175]) In Miida, customer's registration 
requires providing an identification (ID), password, email address, etc. (Miida: Para [180]) Upon a 
successful registration, a registered customers may access the customer pages by providing a valid 
ID and password. (Miida: Para [181]) Based on the ID provided by the customer, Miida's system 
determines which particular copier the custormer is interested in and retrieves status information for 
the particular copier. (Miida: Para [184]) However, providing a user's ID and a password is not a 
"recipient proprietary unencrypted data format," recited in Claim 1. If anything, the ID and the 
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password are encrypted data that identifies the user, not the recipient device. 

Miida's user may access the website from any recipient device. In Miida, the recipient 
device does not have a "proprietary unencrypted data format that is understood by only one 
recipient device of a plurality of recipient devices," as claimed. Miida's recipient device does not 
have a "recipient proprietary unencrypted data format that is understood by one recipient device, is 
supported only by one recipient device, and is different than any other recipient proprietary 
unencrypted data format of any other recipient device," as claimed. 

In Miida, the same communication protocols are used to send emails to the users and to send 
web pages to the users. None of Miida 's communications are proprietary to the recipient device. 
None of Miida's data reports is sent in such a way that is unique to the recipient device. None of 
Miida's data reports is sent in a "recipient proprietary unencrypted data format that only the 
recipient device can understand and that only the recipient device supports...," as recited in Claim 
1. 

DUNMORE REFERENCE 
In Dunmore, a user defines a format in which requested data should be provided to the user; 
however, Dunmore's does not maintain for each recipient device a "recipient proprietary 
unencrypted data format that is understood only by that recipient device, is supported only 
by that recipient device, and is different than any other data format supported by any other 
recipient device," as claimed. Dunmore describes a method and system for designing report 
templates that can be used to output report data. (Dunmore: Col. 5, 11. 38-41) The same template 
may be used by various users and the report data may be formatted using the same template for a 
number of users. (Dunmore: Col. 5, 11. 56-58) Therefore, Dunmore 's data is not send in a 
"recipient proprietary unencrypted data format that only the recipient device can understand and 
that only the recipient device supports. . .," as recited in Claim 1 . 

D'AMANDDIO 

D'Amanddio describes sending data reports in various electronic formats to an end-user, but 
none of those formats is proprietary to the recipient's device, as claimed. In fact, D'Amanddio 
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has only one recipient device. (D'Amanddio: Col. 6, 11. 8-10) D'Amanddio does not have a 
"plurality of recipient devices," as claimed, each of which would have had own "recipient 
proprietary unencrypted data format, that is understood by only that recipient device and not by any 
other recipient device, that is supported by only that recipient device and not by any other recipient 
device, and that is different than any other recipient proprietary unencrypted data formats supported 
by any other device," as claimed. 

Therefore, Miida, Lung, and D'Amanddio, individually or in combination fail to describe or 
suggest a "set of recipient proprietary unencrypted data formats, wherein each of the recipient 
proprietary unencrypted data formats is understood by only one recipient device of a plurality of 
recipient devices, each of the recipient proprietary unencrypted data formats is supported only by 
one recipient device and not by any other recipient device of the plurality of recipient devices, and 
each of the recipient proprietary unencrypted data formats is different than any of recipient 
proprietary unencrypted data formats supported by the other recipient devices from the plurality of 
recipient devices," recited in Claim 1. 

Miida, Lung, and D Amanddio, individually or in combination, also fail to describe or 
suggest "extract, from the network device status data, recipient identification data that uniquely 
identifies an intended recipient device of the plurality of recipient devices, select, using the 
recipient identification data, a recipient proprietary unencrypted data format from the set of 
recipient proprietary unencrypted formats, . . .generate, based upon the configuration data, the 
recipient identification data and the network device status data, report data that conforms to the 
recipient proprietary unencrypted data format supported by the intended recipient device of the 
plurality of recipient devices, wherein the network device status data includes the identification data 
that uniquely identifies the intended recipient device so that the report data is routed to the intended 
recipient device," recited in Claim 1. 
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MIIDA REFERENCE 

In Miida, a computer center collects and analyses information from copiers, and provides 
the information to the users who requested it; however, the information collected from Miida' s 
copier does not "uniquely identify an intended recipient device," as claimed. In Miida, neither 
the collected information nor the transmission device has any knowledge about who the recipients 
of the status data are. In Miida, the information collected from the transmission devices does not 
"include identification data that uniquely identifies an intended recipient device so that the report 
data is routed to the intended recipient device," as claimed. In contrast to Miida, according to 
Claim 1, the copier/printer/fax sends network device data that comprises the "recipient 
identification data." Therefore, according to Claim 1, the copier/printer/fax selects the recipient. 
This capability is not described in Miida. 

In Miida, authorized recipients are registered with the center, not uniquely identified by 
the "network device status data, received from a network device," as claimed. In Miida, to 
access a report data, a user has to send customer-identification information to the center 100, and 
the center 100 has to verify whether the user is registered with the customer- ID database 22. 
(Miida, Para [181]) However, Miida 's copiers themselves have no reason to know user' s IDs. 
Therefore, in Miida, the "network device status data" does not include "identification data that 
uniquely identifies an intended recipient device so that the report data is routed to the intended 
recipient device," as claimed. Furthermore, Miida does not "select, using the recipient 
identification data, a recipient proprietary unencrypted data format from the set of . . . formats," as 
claimed. Moreover, Miida does not "generate report data based upon the recipient identification 
data," as claimed. 

DUNMORE REFERENCE 
In Dunmore, a user requests the data from the database, and defines the format in which the 
requested data should be provided; however, the requested data does not include "identification 
data that uniquely identifies an intended recipient device so that the report data is routed to 
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the intended recipient device," as claimed. Dunmore describes a method and system for 
designing report templates that can be used to output report data. (Dunmore: Col. 5, 11. 38-41) 
When the user wishes to actually run the report, the user provides a user report request to a report 
generator. (Dunmore: Col. 5, 11. 56-58) Then, a report generator queries the database system, 
executes a query against the database and outputs the query results in the format specified by the 
user's template. (Dunmore: Col. 5, 11. 56-63) However, Dunmore' s data in the database does not 
include "identification data that uniquely identifies an intended recipient device so that the report 
data is routed to the intended recipient device," as claimed. Furthermore, Dunmore does not "select, 
using the recipient identification data, a recipient proprietary unencrypted data format from the set 
of . . . formats," as claimed. Moreover, Dunmore does not "generate report data based upon the 
recipient identification data," as claimed. 

D'AMANDDIO 

D 'Amanddio describes sending data reports in various electronic formats to an end-user, but 
none of the sources of the data can select a recipient device from a plurality of the recipient 

devices," as claimed. In D 'Amanddio, acoustical devices collect data from an underwater apparatus 
system and send the data to a recipient computer. (D' Amanddio: Col. 6, 11. 8-10) D Amanddio does 
not have "a plurality of recipient devices," as claimed, each of which could be identified by a 
unique "recipient identification data," as claimed. Therefore, D' Amanddio does not "extract, form 
the network device status data, recipient identification data that uniquely identifies an intended 
recipient device of the plurality of recipient devices," as claimed. Furthermore, D Amanddio does 
not "select, using the recipient identification data, a recipient proprietary unencrypted data format 
from the set of . . . formats," as claimed. Moreover, D 'Amanddio does not "generate report data 
based upon the recipient identification data," as claimed. 

In view of the foregoing, it is respectfully submitted that Claim 1 recites one or more 
limitations that are not taught or suggested by Miida, Lung, and D Amanddio, individually or in 
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combination. Therefore, Miida, Lung, and D'Amanddio, individually or in combination, fail to 
teach or suggest the whole subject matter recited in Claim 1. 

Reconsideration and withdrawal of the rejection is respectfully requested. 

CLAIMS 2-6, 8-11 AND 14 

Claims 2-6, 8-11 and 14 all depend from Claim 1 and include all of the limitations of Claim 
1. It is therefore respectfully submitted that Claims 2-6, 8-11 and 14 are patentable over Miida, 
Lung, and D 'Amanddio for at least the reasons set forth herein with respect to Claim 1 . 
Furthermore, it is respectfully submitted that Claims 2-6, 8-11 and 14 recite additional limitations 
that independently render them patentable over Miida, Lung, and D Amanddio. 

In view of the foregoing, it is respectfully submitted that Miida, Lung, and D Amanddio, 
individually or in combination, fail to teach or suggests Claims 1-6, 8-11 and 14. 

Reconsideration and withdrawal of the rejection is respectfully requested. 

REJECTION OF CLAIM 7 UNDER 35 U.S.C. § 103(a) 

In the Office Action, Claim 7 is rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Miida in view of Lung, further in view of D Amanddio and in further view of Krishnaprasad 
et al, U.S. Patent Publication No. 2002/0099687 (hereinafter "Krishnaprasad"). It is respectfully 
submitted that Claim 7 is patentable over Miida, Lung, D Amanddio and Krishnaprasad for at least 
the reasons provided hereinafter. 

Claim 7 depends from Claim 1 and includes all of the limitations of Claim 1 . As previously 
set forth herein, Claim 1 includes one or more limitations that are not taught or suggested by Miida, 
Lung, and D Amanddio. It is respectfully submitted that these limitations are not taught or 
suggested by Krishnaprasad and it is understood that the Krishnaprasad reference was not relied 
upon for teaching or suggesting these limitations, but rather the additional limitations of Claim 7 
relating the XML schema conversion. 

It is therefore respectfully submitted that Claim 7 is patentable over Miida, Lung, 
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D 'Amanddio and Krishnaprasad. 

Reconsideration and withdrawal of the rejection is respectfully requested. 

REJECTION OF CLAIM 13 UNDER 35 U.S.C. § 103(a) 

In the Office Action, Claim 13 is rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Miida in view of Lung, further in view of D' Amanddio and further in view of McGlade, U.S. 
Patent No. 6,41 1,598. It is respectfully submitted that Claim 13 is patentable over Miida, Lung, 
D Amanddio and McGlade, considered alone or in combination, for at least the reasons provided 
hereinafter. 

Claim 13 depends from Claim 1 and includes all of the limitations of Claim 1. As 
previously set forth herein, Claim 1 includes one or more limitations that are not taught or 
suggested by Miida, Lung, and D Amanddio, individually or in combination. 

Moreover, it is respectfully submitted that these limitations are not taught or suggested by 
McGlade and it is understood that the McGlade reference was not relied upon for teaching or 
suggesting these limitations, but rather the additional limitations of Claim 13 relating to providing a 
notification if a receipt confirmation indicating receipt of the report data is not received from a 
particular recipient device. 

It is therefore respectfully submitted that Claim 13 is patentable over Miida, Lung, 
D Amanddio and McGlade. 

Reconsideration and withdrawal of the rejection is respectfully requested. 
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CONCLUSION 

It is respectfully submitted that all of the pending claims are in condition for allowance and 
the issuance of a notice of allowance is respectfully requested. If there are any additional fees, 
please charge them to Deposit Account No. 50-1302. 

The Examiner is invited to contact the undersigned by telephone if the Examiner believes 
that such contact would be helpful in furthering the prosecution of this application. 

Respectfully submitted, 

HICKMAN PALERMO TRUONG & BECKER LLP 

Date: August 11, 2009 /MalgorzataAKulczycka#50496/ 

Malgorzata A. Kulczycka 
Reg. No. 50,496 

2055 Gateway Place, Suite 550 
San Jose, California 95 1 10 
Telephone:(408) 414-1228 
Facsimile: (408)414-1076 
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